В этом файле содержится краткий отчёт о проделанной работе. Основной код написан на С++ и находится в файле main.cpp в той же директории. Все используемые изображения находятся в папке images. Директория bash_build предназаначена для сборки через cmake. CMakeLists.txt так же лежит в этой же директории.

Для начала продемонстрирую работу написаного кода. Есть 2 режима: просто демозаикинг (на случай если оригинала нет) и демозаикинг с последующим сравнением с оригиналом. Запустим просто демозаикинг на паре картинок, которые удалось найти на просторах Интернета. Для этого я запускала следующие команды из директории bash_build:

cmake ..

cmake --build .

./task_1 ../images/Raw_bayer.png ../images/from_raw_bayer.png

./task_1 ../images/jen-bayerized.jpg ../images/from_jen-bayerized.jpg

У меня получилось время работы:

Время работы алгоритма в секундах: 0.019333

Время работы алгоритма в секундах: 0.013953

Это вполне нормально: картинки достаточно маленькие.

Посчитаем время работы в секундах на мегапиксель:

Время получилось разным. Замечу, что 2-ая картинка меньше и могут сказываться эффекты от постоянных копирований и сравнений.

Теперь перейдём к основному изображению. Чтобы запустить режим со сравнением достаточно в конце дописать название файла с оригиналом. НО если оригинал не совпадёт по размеру или типу с исходным изображением, то программа не только не сравнит изображения, но и вообще не сделает ничего. Это сделано намеренно: если работа завершается исключением, значит вызов был некорректен и мы не должны были испортить исходные данные. В том числе мы не должны были перезаписать выходной файл. Запускаем:

./task_1 ../images/RGB_CFA.bmp ../images/CFA_restored.bmp ../images/Original.bmp

Получаем

Время работы алгоритма в секундах: 0.973268

PSNR = 24.9184

PSNR служит мерой разницы между оригиналом и изображением, полученным с помощью демозаикинга. Для 8-битного изображения это вполне хороший результат, сопостовимый с помехами при передаче по сети.

Снова пересчитаем время работы:

Стало даже ещё лучше, но меня это начинает смущать. Признаю, что я замеряю именно время работы самого алгоритма. Т. е. паддинг и копирование перед выполнением, а так же побрезка и копирование после выполнения не попадпют в часть кода, на которой я засекала время.

Не хотелось бы кого-либо обнадёживать, поэтому время работы я просто усредню:

Характеристики системы:

Получена командой sudo lshw -short

Теперь посмотрим на получившееся изображение и оригинал

Вышло похоже. Считать полосы для определения снижения разрешения вручную будет сложно. Поэтому я выделю наиболее интересные части изображения и построю их яркость - так я смогу проверить, различимы полосы или нет.

Cначала посмотрим на края: 4 группы полос на зашумлённых частях.

Надо признать, что с поворотом возникли некоторые проблемы. Так что все графики повёрнуты относительно выделенных на изображении прямоугольников на 90 градусов против часовой стрелки. Тем не менее я могу различить все линии и больше не буду задерживаться на данных частях изображения.

Теперь смотрим на 2 группы косых полос в верхней части посередине:

Первая группа на восстановленном изображении уже вызывает некоторые вопросы. Появляется неприятная глазу рябь, в то время как на оригинале всё вполне чисто и аккуратно. Пока я всё же могу назвать точное число полос. Второая группа более разреженная и к ней вопросов нет.

Теперь 2 вертикальные группы у центра изображения.

В первой группе всё видно и в оригинале и в восстановленном изображении. Вторая группа, видимо, будет для меня одной из основных в определении разрешения. На восстановленном изображении различия между полосами теряются в районе отметки 13, что соответствует разрешению 1300, а на оригинале - в районе отметки 15, что соответствует разрешению 1500. Но пока рассмотрены далеко не все направления.

Теперь буду заниматься конструкцией посередине. Уже понятно, что разрешения стоит искать между 1100 и 1700, поэтому прямоугольник будет сильно сдвинут вправо.

Мне пришлось разбить изображение на 3 части.

В первом прямоугольнике:

с окружностями всё в порядке, но различить линии не получается.

Во втором прямоугольнике:

для оригинала линии начинают смешиваться на отметке 16, а для восстановленного изображения - на отметке 14.

В третьем прямоугольнике:

уже всё ровно и линии различимы.

Две вертикальные линейки: сначала левая, потом правая.

На втором прямоугольнике пр 9.5 начинается некоторое размытие полос на фиолетовом фоне.

Как ни странно, косые полосы выглядят вполне аккуратно. Даже те, что на голубом фоне вполне различимы. Поэтому этот график никак не повлияет на разрешение.

Осталась нижняя линейка

На это в принципе достаточно тяжело смотреть, но мне кажется что часть с отметкой 10 для восстановленного изображения рябит несколько больше.

Картина примерно та же: с оригиналом всё в порядке, а восстановленное изображение начинает рябить на отметке 10.

Выводы:

Алгоритм работает и достаточно быстро. Среднее время около 0.23 секунд на мегапиксель.

На тестовом изображении RGB_CFA.bmp удалось получить

Предельное разрешение восстановленного изображения из всех рассмотренных частей тестового изображения я оцениваю в 950, предельное разрешения оригинала, я оцениваю в 1500. Получаем, что разрешение снизилось в $\approx 0.63$ раза.